home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19980901-19981211
/
000194_news@newsmaster….columbia.edu _Fri Oct 23 09:50:54 1998.msg
< prev
next >
Wrap
Internet Message Format
|
1998-12-10
|
4KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id JAA15873
for <kermit.misc@watsun.cc.columbia.edu>; Fri, 23 Oct 1998 09:50:54 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id JAA02407
for kermit.misc@watsun; Fri, 23 Oct 1998 09:50:53 -0400 (EDT)
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Stop automatic resetting of terminal emulation?
Date: 23 Oct 1998 13:50:49 GMT
Organization: Columbia University
Lines: 51
Message-ID: <70q1jp$426$1@apakabar.cc.columbia.edu>
References: <Pine.WNT.4.05.9810220906420.169-100000@neko.dental.washington.edu> <zr359kB7TU8S@cc.usu.edu> <70ofhk$e9d$1@apakabar.cc.columbia.edu> <wegLF5YIzlTM@cc.usu.edu>
NNTP-Posting-Host: watsun.cc.columbia.edu
Xref: news.columbia.edu comp.protocols.kermit.misc:9390
In article <wegLF5YIzlTM@cc.usu.edu>, Joe Doupnik <jrd@cc.usu.edu> wrote:
: ...
: Life would have been simpler if there had been both adherence to
: the list of terminal names and timely expansion of the same, and vendors
: who read before pressing keys. But like Unix itself, things got out of
: control irreversibly.
:
Especially nowadays when computers are big-business and mass-market
consumer items. The careful attention once paid to standards -- their
formulation, and subsequent adherence to them -- is pretty much out the
window.
Yet I believe we must support the standards process, both by participating
in it and by following standards even sometimes in cases when we don't
necessarily agree with them (well, within reason).
The problem at hand is what to do when the client says "I have terminal
type xyz" and the host does not understand the name "xyz". The TELNET RFCs
allow two approaches. One is simple: do nothing, in which case the user
can recover by hand. The other is to negotiate through a list until an
agreeable type is found. The tradeoffs between control (favored by the
knowledgable user) and "seamlessness" (for the less knowledgable) are
obvious.
The problem with the latter occurs not so much because a particular name
does not appear in a list at the IANA, but because no semantics are
attached to the names in the IANA terminal-type list. Of course, when the
list was started, no semantics were needed since terminal names referred to
real physical devices with well-defined properties, published in technical
manuals. Nowadays, many "terminal types" exist only as software
abstractions with no physical counterparts, while others are improper
emulations of physical terminals that no longer exist and whose technical
manuals are no longer available.
As noted previously in this discussion, the ANSI name is virtually
meaningless, since many vendors (and makers of shareware, freeware, etc)
have appropriated this term and applied it to their mutually incompatible
products. This gives rise to difficulties such as the one we see when
trying to match terminal types between Kermit 95 and an SCO host, described
in a previous posting. The problem in this case, however, is SCO's, and was
reported to them (by us) long ago, and has been addressed (partially) in SCO
Open Server 5.0.5:
http://www.sco.com/cgi-bin/ssl_reference?109521
As Jeff noted, the automatic matching of terminal type tends to be
beneficial for the typical Kermit 95 user, who -- in 1998 -- is less of a
tinkerer than the typical MS-DOS Kermit user. Thus, I think MS-DOS Kermit
behaves appropriately for its constituency, and so does Kermit 95.
- Frank